1. Field of the Invention
The present invention generally relates to computer software and, more particularly, to an apparatus and method for replacing a running program code and data within the same process of a computer program.
2. Description of Related Art
As known in the computer and software arts, software programs undergo many changes during their product life. The changes either enhance the system through updates or remove problems (i.e., bugs) from the program steps. In either circumstance, the software program is usually replaced with a new version of the program.
Typically, when a software program is replaced with a new version, the old version of the program is terminated and the new version is started. This, however, creates a problem where the program operation is interrupted for some time period.
While there are some solutions for on-line software version changes, these techniques suffer from the following problems. One problem with computer systems in the prior art that are designed to allow real-time software updates is that they require a special operating system or support changes within the operating system. These changes may include modifications to the compilers and/or linkers.
Another problem is that operating systems designed to allow software program updates on-line or on-the-fly, use indirect addressing tables to link different modules together utilizing complicated mechanisms. The use of indirect addressing tables impacts the performance of the overall system software.
The prior art also suffers the problem of transferring the state from the old process to the new process, along with transferring control using the stack monitoring system. However, this transferring of the state to the new version program in the new process suffers the following performance problems.
First, the main function of the program in either the old version or the new version can never change.
While the stack can be used and transferred from the old program in the old process to the new program in the new process, no new procedure area layers can be added. New procedure area layers cannot be added because they would cause errors in the processing since they would be returning to procedures at different addresses.
Furthermore, when transferring control from an old version of a program in an old process to a new version of a program in a new process, the assumption that the program counter can be converted implies that the offset to a function or procedure may never change due to the offset addressing within the version of the program.
Transferring from an old program/process to a new version program/process also assumes that no extra global or static variables can be added or deleted. The reason is that this would cause errors in the execution of the new program/process.
Next, the transfer from an old program/process to a new version program/process implies that the addresses of the data remain constant across the two version, i.e., there is no reordering or optimization changes, etc.
For the return value or parameter format changes, an intraprocedure is written that adds extra overhead on each function call and make it more difficult to maintain the software.
Additionally, stack monitoring techniques cannot guarantee that the old program/process is not performing a time critical task when the state transfer routine is initiated.
Also, the new program/process loses attributes associated with the old process such as the process identification (ID), all the network connections, file connections, and the like, when the old process is terminated to restart within the new process.
In addition, to initiate state transfer, one inserts an illegal instruction and assumes there can be no other causes for this illegal instruction or trap, which would thereby make it possible to initiate a state transfer at the wrong time.
Hence, software users have lacked the ability to allow a program running in a process to be replaced with a new version of a program within the same process without loss of service or state.